Conversation
Signed-off-by: Vincent Biret <vincentbiret@hotmail.com>
Signed-off-by: Vincent Biret <vincentbiret@hotmail.com>
Signed-off-by: Vincent Biret <vincentbiret@hotmail.com>
Signed-off-by: Vincent Biret <vincentbiret@hotmail.com>
handrews
left a comment
handrews
left a comment
There was a problem hiding this comment.
This is getting quite close! BTW, I have only had time to review the markdown file, I hope someone else can look at the tests and schemas, and just ping me if there are questions you can't resolve.
Co-authored-by: Vincent Biret <vincentbiret@hotmail.com>
| Implementations MUST NOT treat an `extends` value as unresolvable before checking all possible target [[OpenAPI]] Description documents provided to the implementation. | ||
|
|
||
| To ensure interoperability, when a target [[OpenAPI]] Description defines `$self`, the Overlay's `extends` value MUST match the target's `$self` URI. | ||
| To ensure portability, when a target [[OpenAPI]] Description defines `$self`, the Overlay's `extends` value SHOULD match the target's `$self` URI. |
There was a problem hiding this comment.
[I also apologize for failing to hit send on this two days ago]
I apologize for not noticing this earlier, but I'm not sure "interoperability" is the ideal word here.
This is really more about portability (of the documents) than interoperability. Given the same input, implementations would be expected to resolve the references the same way. I suppose this is a bit more interoperable as implementations might have different ways to figure out the current document's location for resolving a relative extends, but... hmm... I think this is more about portability of document sets. idk, does anyone else think "interoperability" is better here?
There was a problem hiding this comment.
portability works great! I believe we have already applied the suggestion, anything else?
2 participants
fixes #310
heavy use of GCC to put this one together. (based on the discussion in the issue, and the arazzo PR as a template)